What

This PR makes two targeted SVS fixes:

1. Change SvsFlatIndexNode::Search's guard from

if (!bitset.empty()) {
    return ... not_implemented ... "SVS Flat does not support bitset filtering";
}

to

if (!bitset.empty() && bitset.count() > 0) {
    return ... not_implemented ...
}

so an allocated-but-all-clear bitset is treated as an unfiltered search.

2. Add the missing raw SVS_VAMANA registration in src/index/svs/svs_vamana.cc:

KNOWHERE_MOCK_REGISTER_DENSE_FLOAT_ALL_GLOBAL(SVS_VAMANA, SvsVamanaIndexNode, knowhere::feature::NONE)

This matches the existing Type() implementation and the existing SVS_VAMANA_LVQ / SVS_VAMANA_LEANVEC registrations.

BitsetView::count() (include/knowhere/bitsetview.h:50) returns the number of filtered-out bits / ids — 0 for an all-clear bitset even when empty() is false — so the new SVS_FLAT check is cheap and does not walk the bitmap.

Why

These are two separate SVS correctness issues surfaced by vecTool nightly coverage:

• SVS_FLAT bitset semantics: downstream callers can pre-allocate a BitsetView matching the base-set size and leave all bits clear for plain kNN. Before this PR, SVS_FLAT rejected that semantic no-op bitset immediately instead of searching.
• Raw SVS_VAMANA factory registration: remote Knowhere source defined INDEX_SVS_VAMANA and SvsVamanaIndexNode, but only registered SVS_VAMANA_LVQ and SVS_VAMANA_LEANVEC in the SVS registration block. That leaves raw SVS_VAMANA constructible in code but missing from the global registration path.

Evidence from vecTool nightly

Running vecTool's L2 SVS smoke on zilliztech/vecTool@newNightly with WITH_SVS=ON:

• Before the SVS_FLAT guard fix: all 6 SVS_FLAT groups (cohere_1m × fp32/fp16/bf16 and qwen3vl_200k × fp32/fp16/bf16) fail identically at search with:

E index_wrapper.cpp:168] Failed to search with index: SVS Flat does not support bitset filtering
E knowhere_search.cpp:145] Knowhere search failed: std::exception

• After the SVS_FLAT guard fix in a local build: those 6 groups return search results normally.

For raw SVS_VAMANA, the remote GitHub source showed the registration gap directly:

• src/index/svs/svs_vamana.cc returned INDEX_SVS_VAMANA from Type() but only registered SVS_VAMANA_LVQ and SVS_VAMANA_LEANVEC in the registration block.

Context: zilliztech/vecTool#21.

Test plan

• Build Knowhere with the updated svs_flat.cc and svs_vamana.cc
• Verify SVS_FLAT accepts all-clear bitsets and still rejects bitsets with filtered entries
• Verify the source diff now includes raw SVS_VAMANA registration alongside LVQ and LeanVec

Semantics check

• bitset.empty() == true → short-circuit evaluation, falls through (unchanged)
• bitset.empty() == false && bitset.count() == 0 → falls through (new fast-path, matches other index families)
• bitset.empty() == false && bitset.count() > 0 → same not_implemented return as today (unchanged)

Scope

This PR does not address vecTool nightly policy choices such as which svs_search_window_size values the downstream matrix runs. It only fixes the Knowhere-side SVS_FLAT bitset semantics and the missing raw SVS_VAMANA registration.

Signed-off-by: jamesgao-jpg james.gao@zilliz.com